1 trunk上开发
页游A
trunk和branch同时开发，trunk上进行周版本迭代，branch上是大版本功能开发(2周到4周），开发完合并到trunk。不打tag，通过trunk发布。所有资源后跟版本号: *.swf?fileversion=xxxx，测试和外网bug都在trunk上fix
页游B
trunk和branch同上，但每周发布打tag，资源URL通过tag名进行区分，例如
http://res.xxx.com/tagName/config.xml
tagName通过一个version.js发布，不同资源的tagName可能不一样，测试和外网bug都在trunk上fix
对页游来讲，tag的作用貌似不大，因为每次获取的都是最新的版本
手游A
trunk和branch同上，看情况可以trunk发布，也可以branch发布后再合并到trunk，不打tag。开始没用lua，无法热更新，运营活动只更新资源，更新代码需要发布新版本并强制用户更新
客户端A
在trunk上开发，没有branch，在trunk上bugfix和发布，打tag，进入下一个版本的开发。和游戏不一样，客户端A需要维护多个版本。tag_release_1.0出问题，基于tag_release_1.0拉分支bugfix_tag_release_1.0，完成后，基于bugfix_tag_release_1.0做发布。最后选择性地将bugfix_tag_release_1.0合并到trunk中（因为此时trunk已经在下一个版本中了）
后来加入branch，主要是有些功能模块时间跨度长达半年，甚至更长。在此期间，branch需要经常把trunk上的更新合并过来
2 trunk只做发布
客户端B
也需要维护多个版本，上头想改成这种方式，有待实践，也是这次整理的目的
trunk上只做release，从一开始就拉分支dev_1.0，完成后（包括bugfix)，合并到trunk，打tag（tag_release_1.0），拉分支dev_2.0进行下一版本开发。tag_release_1.0发布后发现问题，基于tag_release_1.0拉分支bugfix_tag_release_1.0。完成后，若dev_2.0还在开发阶段，则将bugfix_tag_release_1.0合并到trunk，通过trunk打tag发布；若dev_2.0已开发结束合并至trunk，则基于bugfix_tag_release_1.0做发布，最后选择性地将bugfix_tag_release_1.0合并到trunk中。
以上的描述似乎和客户端A的开发方式没什么差异，上头是想在dev_1.0后同时插入多个分支，如dev_1.1，dev_1.2，dev_1.3。有些release只需要dev_1.1和dev_1.2，不需要dev_1.3；有些release只需要dev_1.1和dev_1.3，不需要dev_1.2；这貌似是插件化的开发方式，另外一个主题了。先看着办吧。